前兩天介紹我的轉職學習與求助資源，多少提到自己在職場的學習，而相信對程式新手而言，QA是相對陌生的職位，因此，想藉今日分享我所理解的分工與職務內容。

什麼是QA？為什麼需要QA？

註：目前是在軟體新創，比較偏向分享這樣組織的QA，並以純軟為主

試想一下？有沒有曾經買過一些服務或產品，對方描述都很棒，也有一些不錯的評價，真正開始使用才發現各種困難。可能是設計對使用者不友善，或者在某些情境效能不佳，甚至跟該公司的宣稱有所抵觸。

這就跟研究與實務可行的落差一樣，即使研發團隊盡全力確保自己的程式在效能與功能正確，不會突然crash，也沒有邏輯錯誤，受限於設計者本身對產品太過習慣，與使用情境太過單一，沒有真正經過測試的產品是很難直接進入市場。

這就是QA存在的重要性：

1. 依據各種使用者可能使用的情境，確保產品都能正確運作
2. 協助PM\RD\sales等夥伴釐清產品問題，並給予改善建議
3. 在開發新功能時，基於對使用者與使用情境的理解，給予設計與實現建議

在團隊中的定位，通常有以下不同形式：

1. QA直接在研發團隊中，技術導向，與RD高密度協作，大幅度自動化，從工程角度給予實現方法與架構建議
2. QA歸屬於PM，依據產品roadmap排定每一次測試進度，更類似QC，可能影響RD進度
3. 獨立QA部門，跟RD平行，直屬於產品長

這些分類很可能並行或隨組織需求變動，最終目的都是希望確保開發產品的品質與增進用戶滿意度。

當產品成熟，QA就更重要

對新創公司而言，產品開發會分幾個階段，也反映對不同職能的需求：

1. 研發初期：設計師與RD為主幹，盡全力設計與實現重要功能，確認初步的商業模式
2. 研發中期：業務開始變得重要，必須與研發人員討論可接觸用戶與優化商業模式，也會從用戶中得到反饋來優化設計
3. 研發後期：產品趨於成熟，已有一些用戶（確認市場反應友善且能賺到一些錢），愈來愈在意品質，因此邀請QA加入

在開發愈來愈敏捷的情境下，客戶變多、實現的需求變得複雜，發版的速度也變得愈來愈快速，直接讓PM\RD\designer等大量測試使用者情境，可能嚴重影響原本業務，專職的QA可以減輕其他職位的負擔。

我的工作以每週、每個月的區分：

1. 每個月：
   1. 配合客戶需求，通常一個月會有大型版本更新，因此每個月會有一段已知密集測試期
   2. 依據功能的重要程度，與設計師、RD討論確認roadmap，並給予自己長期操作產品的反饋，協助設計師優化設計或挪動milestone
   3. 持續因應roadmap修繕測項與自動化測試實現，以促進產品測試效率與品質
2. 每一週：
   1. 依據客戶反饋，可能有在公司情境測試中仍未發現的事件，QA需要協助團隊去釐清特定環節出現問題
   2. 若有緊急修復產品，通常在一天內完成測試並回覆結果，反饋通常會細緻到RD程式碼可能出錯處的猜測

為什麼需要自動化測試？如何執行？

在上列描述，應該可感受到測試需求非常高，且要求效率，而自動化的好處是：

1. 品質一致：人為操作測試可能每人標準不同，同一人當下測試狀況有差，造成品質不一致，將無法協助團隊掌控產品
2. 增加效率：工程師都很厭惡重複性活動，最好的方法就是用工具解決麻煩，使人能做更有效益的事
3. 結果清晰：在工具串接完整的情境下，很能直接讓系統跑完測試，輸出報告，使成員們易於偵錯

常見工具：以 微軟應用程式 的 UI testing 為例

1. winappdriver：

• 是一套特別支援微軟產品的selenium工具，當時selenium被發展的目的，便是希望自動驅動網頁，可獲取產品的即時訊息，在測試應用上，可依據工程師的指定，自動模擬使用者按照特定順序與方式去操作產品，以達到所謂的UI testing
• 舉例來說，可以實現去點擊某個頁面、捲動頁面、填入資訊等，各種我們在網頁上會採取的行動
• 目前selenium API已經幾乎支援各類主流語言，可依據使用需求，選擇裝載的工具與撰寫語言。因為我經手產品架構以C#為主，也相對是開發測試微軟產品最佳選項，因此採取支援C#的winappdriver

2. visual studio：

• 微軟針對開發C#需求的整合開發環境，可以在裡面架設專案架構、進行撰寫，也支援測試程式的撰寫與執行
• 跟微軟另個產品VS code完全不一樣，這是相容於各種OS的編輯器，在mac操作特別方便

3. inspect:（請點入連結了解更多）

• 應用程式不像我們打開網頁原始碼或點選檢查就能一覽無遺，原有架構跟真實呈現也可能有落差，inspect是微軟協助工程師去確認微軟產品UI的工具，可看到特定物件的名稱、類型、隸屬層次等資訊，直接成為自動化測試撰寫所用資訊，以協助工程師抓取明確對象、測試該行為

實際執行方式，將會在之後文章深入分享，現在不特別贅述

在結尾則想提到我猜想 什麼樣的人適合QA\QA適合什麼樣的人，以及我所理解的 QA可帶來的好處\困境

對應業務與特質：

1. 品質把關者：需有耐心與細心，不會對每天重複性工作不耐煩且降低品質
2. 理解使用者需求：UIUX經驗或業務，多少都對使用者需求比較敏感，也自帶易用性測試的mindset
3. 良好溝通能力：中間很常需要同時理解設計、RD、業務端的需求與想法，很可能需要轉譯彼此語言

QA經驗可帶來的好處：

1. 工程菜鳥快速上手產品開發：模仿是一種學習的方式，撰寫自動化測試需要大量閱讀理解RD所寫內容，這些過程會刺激自己查詢更多資料與熟悉產品開發架構，有機會成為切入研發的跳板
2. 建置完整產品觀：不同於RD任務會切分很細，有時難免不暸解整體需求，QA很需要跟著客戶需求，在比較整合的層次思考問題，所理解也相對全面

QA的困境：

1. 時間永遠不夠：大家都知道理想上所有測試應該都被自動化，但耳聞不同公司的QA皆常見測試業務量太大，總有很多測試無法被自動化，產生測試的不效率
2. 測試與研發語法邏輯不同：雖然都撰寫同一語言，但會用到功能與思考架構幾乎不同，會造成難以建立研發類型常用的語法與習慣
3. 未必能轉RD成功：上述兩個問題帶來能力與經驗的限制，願意投入的QA也會讓主管未必想放手，多會繼續安排相關業務

目前的對策：

1. 選擇較為彈性的新創組織，主管比較open-mind者
2. 積極爭取任何接近研發的業務，有機會就實作證明自己實力
3. 利用任何空檔與非上班時間栽培自己

總結上述，QA在逐漸完整的研發體系中扮演逐漸重要角色
雖然可能是轉職者初步理解研發的敲門磚，也可能成為限制
為有足夠積極與釐清自己目標，才能使QA成為墊腳石非絆腳石